frontend/src/main/services/browser/search.ts (1)

1-4: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Remove unused imports.

Multiple unused imports have been identified: WebContentsView, attachView, detachView, setViewBounds, calculateBounds, and DEFAULT_BROWSER_CONFIG.

🧹 Proposed cleanup

-import { WebContentsView, BrowserWindow } from 'electron'
-import { createBrowserView, attachView, detachView, setViewBounds, isViewDestroyed } from './view'
-import { calculateBounds } from './view'
-import { DEFAULT_BROWSER_CONFIG } from './types'
+import { BrowserWindow } from 'electron'
+import { createBrowserView, isViewDestroyed } from './view'

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/main/services/browser/search.ts` around lines 1 - 4, The listed
imports are unused—remove the unused specifiers WebContentsView, attachView,
detachView, setViewBounds, calculateBounds, and DEFAULT_BROWSER_CONFIG from the
top of frontend/src/main/services/browser/search.ts so only the actually used
symbols (e.g. createBrowserView, BrowserWindow or any others referenced later in
the file) remain; update the import statements from './view' and './types' to
only export the symbols that are referenced by functions like createBrowserView
and any BrowserWindow usage to eliminate linter/compile warnings.

backend/app/utils/tool_parameter_extractor.py-184-185 (1)

184-185: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Consider the UX impact of appending "时间" to short queries.

When a query is 3 characters or fewer, the code unconditionally appends " 时间". This might produce awkward search queries for non-time-related searches (e.g., "红楼梦" → "红楼梦 时间").

Consider restricting this suffix to queries that match time-related patterns or removing it if the search intent is not time-based.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/tool_parameter_extractor.py` around lines 184 - 185, The
code currently appends the suffix " 时间" to any short query (variable query) when
len(query) <= 3; change this to only append when the query appears time-related
by checking for time patterns (e.g., digits or year tokens like "年", "月", "日",
"年代", or explicit time words) using a simple regex, or replace the unconditional
append with a call to an intent check (e.g., an is_time_query(query) helper)
that returns true only for time-related queries; update the block that
references query in tool_parameter_extractor.py to perform the pattern/intent
check before adding " 时间" so non-time short queries (e.g., "红楼梦") are left
unchanged.

frontend/src/renderer/src/components/FilePreview.vue-19-45 (1)

19-45: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add error handling for base64 decoding.

The handleDownload function assumes fileContent is a well-formed data URL for images. If the format is unexpected (e.g., missing comma, invalid base64), split() or atob() will throw, leaving the user with no feedback.

Wrap the decoding logic in a try-catch block and show a user-friendly error message on failure.

🛡️ Proposed error handling

 const handleDownload = () => {
   if (!props.fileContent) return
   
+  try {
     let blob: Blob
     if (isImage.value) {
       const base64Data = props.fileContent.split(',')[1]
+      if (!base64Data) throw new Error('Invalid image data')
       const byteString = atob(base64Data)
       const mimeType = props.fileContent.split(':')[1].split(';')[0]
       const ab = new ArrayBuffer(byteString.length)
       const ia = new Uint8Array(ab)
       for (let i = 0; i < byteString.length; i++) {
         ia[i] = byteString.charCodeAt(i)
       }
       blob = new Blob([ab], { type: mimeType })
     } else {
       blob = new Blob([props.fileContent], { type: 'text/plain' })
     }
     
     const url = URL.createObjectURL(blob)
     const a = document.createElement('a')
     a.href = url
     a.download = props.fileName
     document.body.appendChild(a)
     a.click()
     document.body.removeChild(a)
     URL.revokeObjectURL(url)
+  } catch (err) {
+    console.error('Download failed:', err)
+    alert('下载失败，请稍后重试')
+  }
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/components/FilePreview.vue` around lines 19 - 45,
The handleDownload function assumes props.fileContent is a valid image data URL
and decodes it without protection; wrap the image decoding block (the code that
reads base64Data, calls atob, computes mimeType, fills the ArrayBuffer and
creates the Blob) in a try-catch that catches errors from split/atob/decoding,
aborts the download flow on failure, and surfaces a user-friendly error (e.g.,
via an alert, a toast, or emitting an error event) so the user gets feedback;
ensure you do not create the object URL or trigger a click if decoding failed
and keep references to isImage and props.fileContent/fileName to locate the
code.

backend/app/utils/intent_gateway.py-317-323 (1)

317-323: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Remove duplicate "油价" entry.

Line 321 contains a duplicate "油价" entry in the _TOOL_KEYWORDS_REALTIME set. While Python will automatically deduplicate this, it should be cleaned up for code clarity.

🧹 Proposed fix

 _TOOL_KEYWORDS_REALTIME = {
     "股价", "股票", "行情", "汇率", "油价", "金价", "房价",
     "限行", "限号", "停水", "停电", "快递", "物流",
     "招聘", "求职", "签证", "出入境", "入境政策",
-    "油价", "汽油价", "黄金价", "二手房", "均价",
+    "汽油价", "黄金价", "二手房", "均价",
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/intent_gateway.py` around lines 317 - 323, Remove the
duplicate "油价" entry from the _TOOL_KEYWORDS_REALTIME set to improve clarity;
locate the _TOOL_KEYWORDS_REALTIME definition in intent_gateway.py and delete
one of the two "油价" items so each keyword appears only once.

backend/app/utils/intent_gateway.py-137-148 (1)

137-148: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Remove duplicate "发布会" entry.

Line 147 contains a duplicate "发布会" entry in the event_date_keywords set. While Python will automatically deduplicate this, it indicates a copy-paste error and should be cleaned up for code clarity.

🧹 Proposed fix

         self.event_date_keywords: set[str] = {
             "软考", "考研", "高考", "中考", "国考", "省考",
             "考公", "公务员", "事业编", "选调", "教资", "法考",
             "注会", "一建", "二建", "复试", "笔试", "面试",
             "报名", "准考证", "成绩", "录取", "分数线",
             "世界杯", "奥运会", "亚运会", "世博会", "欧冠",
             "NBA", "欧洲杯", "亚洲杯", "全运会",
             "上映", "开售", "预售", "发售", "发布",
             "开学", "放假", "开学季", "毕业",
             "春运", "假期", "调休",
-            "发布会", "发布会", "直播",
+            "发布会", "直播",
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/intent_gateway.py` around lines 137 - 148, The set
event_date_keywords in intent_gateway.py contains a duplicate "发布会"; remove the
redundant "发布会" entry from the self.event_date_keywords initialization so the
set literal is clean (keep only one "发布会" in the set defined in the __init__
where event_date_keywords is declared).

frontend/src/renderer/src/components/FileUpload.vue-24-36 (1)

24-36: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

FileCard :size="0" should reflect actual file size.

The FileCard component receives :size="0" which doesn't represent the actual uploaded file size. This will display incorrect information to users.

Root cause: The useFileUpload composable doesn't store the original File object's size. When uploadAndForward(file) is called, only the file name is stored in uploadingFile.value.name, but file.size is lost.

Suggested fix:

1. In useFileUpload.ts, add fileSize to the reactive state
2. Store file.size when upload starts
3. Pass it to FileCard as :size="fileSize"

🔧 Proposed fix

In useFileUpload.ts:

 const uploadingFile = ref<{ name: string; status: 'uploading' | 'success' | 'failed'; type?: string; result?: string; error?: string } | null>(null)
 const isUploading = ref(false)
 const parsedContent = ref('')
 const fileType = ref('')
 const fileName = ref('')
+const fileSize = ref(0)
 
 export function useFileUpload() {
   const uploadAndForward = async (file: File): Promise<string> => {
     ...
     uploadingFile.value = { name: file.name, status: 'uploading' }
+    fileSize.value = file.size
     ...
   }
   
   const clearUploadState = () => {
     ...
     fileName.value = ''
+    fileSize.value = 0
   }
   
   return {
     ...
     fileName,
+    fileSize,
     uploadAndForward,
     clearUploadState,
   }
 }

In FileUpload.vue:

-const { uploadingFile, isUploading, uploadAndForward, clearUploadState } = useFileUpload()
+const { uploadingFile, isUploading, fileSize, uploadAndForward, clearUploadState } = useFileUpload()
 
 <FileCard
   v-if="uploadingFile"
   :name="uploadingFile.name"
-  :size="0"
+  :size="fileSize"
   :status="uploadingFile.status"
   :error="uploadingFile.error"
   `@remove`="clearUploadState"
-  `@download`="() => {}"
+  `@download`="() => {}"  
 />

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/components/FileUpload.vue` around lines 24 - 36,
The FileCard currently receives a hardcoded :size="0" because useFileUpload's
uploadingFile doesn't store the original File.size; update the composable
(useFileUpload, specifically the uploadAndForward function and the reactive
uploadingFile state) to include fileSize (or size) and set it to file.size when
an upload starts, expose that property (e.g., uploadingFile.value.size or a
separate fileSize ref), then in FileUpload.vue replace :size="0" with the real
prop (e.g., :size="uploadingFile.size" or :size="fileSize") so the FileCard
shows the correct size and ensure clearUploadState clears the size field as
well.

backend/app/utils/tool_result_processor.py-302-309 (1)

302-309: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Register the new weather tool name here too.

This registry special-cases get_weather, but the MCP server added in this PR exposes get_weather_info. As written, MCP weather results will skip the dedicated formatter and fall back to the generic path.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/tool_result_processor.py` around lines 302 - 309,
TOOL_PROCESSORS currently maps "get_weather" to _process_weather_result but the
new MCP tool uses the name "get_weather_info", so update the registry by adding
an entry that maps "get_weather_info" to _process_weather_result alongside the
existing "get_weather" key; modify the TOOL_PROCESSORS dict to include
"get_weather_info": _process_weather_result so MCP weather results use the
dedicated formatter.

backend/app/api/v1/endpoints/chat.py-313-315 (1)

313-315: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

temperature/max_tokens/top_p are silently clobbered to defaults when the caller passes 0.

All five locations use the pattern if request.temperature is not None: loop_kwargs["temperature"] = request.temperature or 0.7. The or 0.7 short-circuits when request.temperature is 0 (a perfectly valid value for greedy/deterministic decoding) or 0.0, replacing it with 0.7. Same applies for top_p=0. For max_tokens=0 the fallback to 4096 is arguably surprising too. Drop the or default — the outer is not None check is already gating injection.

Ruff also flags these lines for E701 (multiple statements on one line); applying the fix below also resolves that.

🛡️ Proposed fix (apply at each of the five locations)

-                if request.temperature is not None: loop_kwargs["temperature"] = request.temperature or 0.7
-                if request.max_tokens is not None: loop_kwargs["max_tokens"] = request.max_tokens or 4096
-                if request.top_p is not None: loop_kwargs["top_p"] = request.top_p or 0.9
+                if request.temperature is not None:
+                    loop_kwargs["temperature"] = request.temperature
+                if request.max_tokens is not None:
+                    loop_kwargs["max_tokens"] = request.max_tokens
+                if request.top_p is not None:
+                    loop_kwargs["top_p"] = request.top_p

Also applies to: 667-669, 701-703, 774-776, 851-853

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/api/v1/endpoints/chat.py` around lines 313 - 315, The current
assignments use "request.temperature or 0.7" (and similar for max_tokens/top_p)
which wrongly replaces valid zero values; update each occurrence where
loop_kwargs is set from request (e.g., the lines that read if
request.temperature is not None: loop_kwargs["temperature"] =
request.temperature or 0.7) to assign the raw value guarded by the is not None
check (e.g., if request.temperature is not None: loop_kwargs["temperature"] =
request.temperature), do the same for request.max_tokens and request.top_p, and
expand the single-line if statements into separate lines to avoid E701 (multiple
statements on one line); apply this change at all five locations where these
patterns appear.

frontend/src/renderer/src/stores/chat.ts-374-378 (1)

374-378: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Accessing m.file_name / m.file_type on a ChatMessage that doesn't declare them.

ChatMessage (in types/index.ts) declares files?: ChatFile[] but no file_name / file_type. The fallback path here reads m.file_name / m.file_type which only type-checks if the iterator value is widened to any (which it currently is because conv.messages originates from a JSON parse). If strict TS is ever enabled this will fail. Either:

1. Add file_name?: string; file_type?: string to ChatMessage as legacy compatibility fields (and document them), or
2. Have the backend always emit files: [...] so the fallback can be removed.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/stores/chat.ts` around lines 374 - 378, The code
reads m.file_name / m.file_type on items from conv.messages even though the
ChatMessage type (types/index.ts) only defines files?: ChatFile[]; fix by making
types explicit: add optional legacy fields file_name?: string and file_type?:
string to the ChatMessage declaration (and document them as legacy
compatibility) so the fallback path type-checks, or remove the fallback and
enforce the backend always emits files: ChatFile[] so msg.files is populated
only from m.files; update references in the chat store (the block using m.files,
file_name, file_type) accordingly.

backend/app/api/v1/endpoints/chat.py-78-99 (1)

78-99: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Server-local datetime.now() is labelled Asia/Shanghai.

datetime.now() returns the host’s local time. If the backend ever runs in a container/host that isn’t set to Asia/Shanghai, the system prompt confidently states a wrong timezone — and the LLM will compute date-diffs against a wrong "now". Use a timezone-aware now:

🛡️ Proposed fix

-def _inject_system_prompt(messages: list[dict]) -> list[dict]:
-    from datetime import datetime
-    now = datetime.now()
+def _inject_system_prompt(messages: list[dict]) -> list[dict]:
+    from datetime import datetime
+    from zoneinfo import ZoneInfo
+    now = datetime.now(ZoneInfo("Asia/Shanghai"))

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/api/v1/endpoints/chat.py` around lines 78 - 99, The system prompt
in _inject_system_prompt uses naive datetime.now(), which can be wrong if the
host timezone differs; change it to a timezone-aware now using
ZoneInfo("Asia/Shanghai") (e.g., import ZoneInfo from zoneinfo and call
datetime.now(ZoneInfo("Asia/Shanghai"))) and then use that tz-aware now to build
current_date, current_weekday and current_time so the date_prompt reliably
states Asia/Shanghai time; keep the rest of the logic (has_system check and
prepending/updating the "system" message) unchanged.

frontend/src/renderer/src/views/MemoryView.vue-290-305 (1)

290-305: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Silent failures in saveEdit / handleDeleteFact.

Both catch {} blocks swallow errors without any user-visible feedback or logging. If the backend update/delete fails, the UI quietly desyncs from server state (edit dialog closes or item appears to be deleted while still present after refresh). Surface the error via a toast/notification (or at minimum re-throw / log), so the user knows the action did not succeed.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/views/MemoryView.vue` around lines 290 - 305, The
empty catch blocks in saveEdit and handleDeleteFact swallow errors and hide
failures from users; update these handlers (saveEdit and handleDeleteFact) to
surface failures by catching the error and either logging it (e.g., to console
or process logger) and showing a user-facing notification/toast, or re-throwing
after logging, when memoryStore.updateFact(...) or memoryStore.deleteFact(...)
rejects (include agentStore.activeAgent?.id when constructing context); ensure
editingFactId/editingContent are only reset after a successful update so the UI
does not desync.

frontend/src/renderer/src/views/WorkspaceView.vue-551-555 (1)

551-555: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

window.__memoryChatTrigger is set at setup time but never cleared on unmount.

The assignment runs once during <script setup> execution (effectively at mount), but onBeforeUnmount does not delete it. After this view is destroyed the global still references the now-unmounted component's closure, leaking the component (and any reactive state it captured via inputText) and silently writing to a stale inputText.value if another component dispatches a memory trigger. Move the assignment into onMounted and clear it in onBeforeUnmount.

🛠️ Suggested fix

-(window as any).__memoryChatTrigger = handleMemoryChatTriggerDirect
-
 onMounted(async () => {
   ...
+  (window as any).__memoryChatTrigger = handleMemoryChatTriggerDirect
 })

 onBeforeUnmount(() => {
   ...
+  if ((window as any).__memoryChatTrigger === handleMemoryChatTriggerDirect) {
+    delete (window as any).__memoryChatTrigger
+  }
 })

Also applies to: 580-590

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/views/WorkspaceView.vue` around lines 551 - 555,
The global window.__memoryChatTrigger is assigned during script setup to the
closure handleMemoryChatTriggerDirect which captures reactive inputText, causing
a memory leak and stale writes after the component unmounts; move the assignment
into onMounted so it only sets window.__memoryChatTrigger when the component is
active and then clear (delete or set to undefined) window.__memoryChatTrigger
inside onBeforeUnmount to remove the reference to
handleMemoryChatTriggerDirect/inputText; update both places where this pattern
appears (the handleMemoryChatTriggerDirect assignment and the similar block
around lines 580-590) so mounting sets the global and unmounting removes it.

backend/app/utils/web_search_tool.py (1)

99-104: ⚡ Quick win

Flatten nested async with statements.

Both the 360 search and DuckDuckGo functions use nested async with blocks. Python allows combining these into a single statement for cleaner code.

♻️ Proposed simplification

For _360_search (lines 99-104):

     try:
-        async with aiohttp.ClientSession(headers=_360_HEADERS) as session:
-            async with session.get(
-                url,
-                timeout=aiohttp.ClientTimeout(total=15),
-                allow_redirects=True,
-            ) as resp:
+        async with aiohttp.ClientSession(headers=_360_HEADERS) as session, \
+                   session.get(url, timeout=aiohttp.ClientTimeout(total=15), allow_redirects=True) as resp:
                 if resp.status != 200:

For _ddg_instant_answer (lines 137-142):

     try:
-        async with aiohttp.ClientSession() as session:
-            async with session.get(
-                _DDG_IA_URL,
-                params=params,
-                timeout=aiohttp.ClientTimeout(total=8),
-            ) as resp:
+        async with aiohttp.ClientSession() as session, \
+                   session.get(_DDG_IA_URL, params=params, timeout=aiohttp.ClientTimeout(total=8)) as resp:
                 if resp.status != 200:

Also applies to: 137-142

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/web_search_tool.py` around lines 99 - 104, The nested
"async with" blocks in _360_search and _ddg_instant_answer should be flattened
into a single combined context manager to simplify the code; replace the pattern
"async with aiohttp.ClientSession(...) as session:\n    async with
session.get(...) as resp:" with a single line combining both contexts (i.e.,
"async with aiohttp.ClientSession(...) as session, session.get(...) as resp:"),
preserving the same timeout, headers, and allow_redirects arguments and keeping
all existing error handling and response handling logic inside the combined
block.

backend/app/utils/tool_parameter_extractor.py (2)

274-277: ⚡ Quick win

Combine the conditional branches for cleaner code.

The conditions on lines 274 and 276 both lead to the same outcome. Combine them using a logical or operator for better readability.

♻️ Proposed simplification

-            elif month >= 5 and month <= 8:
-                enriched = enriched + "下半年"
-            elif month >= 9:
+            elif month >= 5:
                 enriched = enriched + "下半年"

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/tool_parameter_extractor.py` around lines 274 - 277, The
two consecutive branches that both append "下半年" to enriched (the elif month >= 5
and month <= 8 and the elif month >= 9) should be combined into a single
condition to simplify logic; locate the block referencing the month variable and
enriched and replace the two branches with one (e.g., a single elif that covers
month >= 5 or an equivalent simplified condition) so enriched is appended once.

---

291-291: ⚡ Quick win

Add newline at end of file.

Python files should end with a newline character for POSIX compliance and better tooling compatibility.

♻️ Add trailing newline

         return enriched
+

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/tool_parameter_extractor.py` at line 291, Add a single
newline character at the end of the file so it ends with a trailing newline;
ensure the file finishes immediately after the final "return enriched" statement
in tool_parameter_extractor.py (i.e., insert a newline/line break after that
return).

frontend/src/main/services/browser/search.ts (1)

76-80: ⚡ Quick win

Improve cleanup error handling.

The empty catch block silently swallows any cleanup errors. While this might be intentional to prevent exceptions in the finally block, it makes debugging harder.

Consider logging the error or at least adding a comment explaining why errors are ignored.

🔍 Proposed improvement

   } finally {
     try {
       if (!isViewDestroyed(view)) {
         view.webContents.close()
       }
-    } catch {}
+    } catch (err) {
+      console.debug('[BrowserSearch] Cleanup error (ignored):', err)
+    }
   }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/main/services/browser/search.ts` around lines 76 - 80, The empty
catch around the webContents close hides failures; change the catch to surface
at least a warning or explain why it's intentionally ignored: replace the empty
catch with a call to your logger (or console.warn/console.error) including
context and the caught error (e.g., mention view id or type) for the block that
calls view.webContents.close, or if swallowing is deliberate add a concise
comment explaining why exceptions are safe to ignore; ensure references to
isViewDestroyed(view) and view.webContents.close remain and the logged message
provides useful debug context.

backend/app/utils/weather_tool.py (2)

183-298: 💤 Low value

Remove unnecessary f-string prefix.

Line 298 uses an f-string without any placeholders. This is unnecessary and should be a regular string literal for clarity and to avoid potential confusion.

🔧 Proposed fix

     # ---- 兜底：无法解析，按今天处理 ----
     return {"date": today.strftime("%Y-%m-%d"), "type": DateType.TODAY, "day_offset": 0,
-            "error": f"日期格式无法识别，已为你查询今天天气"}
+            "error": "日期格式无法识别，已为你查询今天天气"}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/weather_tool.py` around lines 183 - 298, The final return
in parse_query_date uses an unnecessary f-string for the error message (no
placeholders) — update the error literal in the final return of parse_query_date
(the fallback branch that returns DateType.TODAY with day_offset 0) to a normal
string literal instead of an f-string to remove the redundant f-prefix and
improve clarity.

---

872-894: 💤 Low value

Remove unnecessary f-string prefix.

Line 894 uses an f-string without any placeholders, similar to line 298.

🔧 Proposed fix

         return asyncio.run(_weather_tool.get_reply(city, date_str))
     except Exception as e:
         logger.warning(f"[WeatherTool] get_weather_reply 异常: {e}")
-        return f"天气查询暂时不可用，稍后再试哦~"
+        return "天气查询暂时不可用，稍后再试哦~"

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/weather_tool.py` around lines 872 - 894, In
get_weather_reply, remove the unnecessary f-string prefix on the static return
message; specifically change the return f"天气查询暂时不可用，稍后再试哦~" to a plain string
"天气查询暂时不可用，稍后再试哦~" (leave the logger.warning(f"...{e}") intact since it uses a
placeholder). This fixes the redundant f-string usage in _weather_tool.get_reply
error handling.

backend/app/api/attachment_api.py (1)

157-171: ⚡ Quick win

Consider logging when falling back to lossy UTF-8 decoding.

The encoding fallback strategy (UTF-8 → GBK → UTF-8 with errors='ignore') is reasonable, but the final fallback at line 165 can silently drop characters without notifying the user or logging the event. This could lead to data corruption that's hard to debug.

📝 Add logging for encoding fallback

         text_extensions = {'txt', 'md', 'csv', 'json', 'xml', 'html', 'css', 'js', 'py', 'java', 'cpp', 'c', 'h', 'go', 'rs', 'ts', 'sql', 'yaml', 'yml'}
         if ext in text_extensions:
             try:
                 text = file_bytes.decode('utf-8')
             except UnicodeDecodeError:
                 try:
                     text = file_bytes.decode('gbk')
                 except UnicodeDecodeError:
+                    logger.warning(f"[UploadForward] 文件编码无法识别，使用UTF-8忽略错误模式: {filename}")
                     text = file_bytes.decode('utf-8', errors='ignore')
             return {
                 "status": "success",
                 "content": text,
                 "type": "text",
                 "filename": filename,
             }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/api/attachment_api.py` around lines 157 - 171, When decoding text
files in the ext/text_extensions branch, add a warning log when you hit the
final lossy fallback (file_bytes.decode('utf-8', errors='ignore')) so dropped
characters are recorded; include identifying context (filename, ext and a
snippet or byte-length) and the fact you fell back from UTF-8→GBK→lossy UTF-8
using the project's logger (or the logging module) so callers can trace encoding
issues for functions handling file_bytes and filename in attachment_api.py.

backend/app/utils/time_tool.py (1)

96-152: ⚖️ Poor tradeoff

Lunar calendar data is limited to 2025-2030.

The hardcoded _LUNAR_MONTH_STARTS table only covers years 2025-2030. Queries for dates outside this range will return {"found": False} from _solar_to_lunar().

While the code handles this gracefully with fallback messages (e.g., line 1438-1439), consider:

1. Adding a prominent comment warning about the date range limitation
2. Planning periodic data updates before 2030
3. Or integrating a lunar calendar library if long-term coverage is needed

This is acceptable for a 5-year horizon but requires maintenance planning.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/time_tool.py` around lines 96 - 152, The
_LUNAR_MONTH_STARTS table only covers 2025–2028 (effectively 2025–2030 in
surrounding code) so _solar_to_lunar() will return {"found": False} for dates
outside that range; update the file by adding a prominent top-of-table comment
next to _LUNAR_MONTH_STARTS stating the exact covered years and maintenance
expectations, and either expand the data set (extend tuples through 2030), add a
TODO with a scheduled reminder to refresh the table before expiry, or
replace/augment this hardcoded table by integrating a lunar calendar library
call in _solar_to_lunar() as an alternative long-term solution (reference
symbols: _LUNAR_MONTH_STARTS and _solar_to_lunar).

frontend/src/renderer/src/types/index.ts (2)

60-67: 💤 Low value

reasoning_content required vs useApi.ts defaulting it to ''.

ChatStreamChunk.reasoning_content is declared as required string. That works because apiStream always defaults it to '' when the server omits it, but anyone constructing a ChatStreamChunk literal directly (or any provider returning the field optionally) will trip TypeScript without realizing the empty-string convention. Consider making it optional (reasoning_content?: string) or documenting the empty-string contract here.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/types/index.ts` around lines 60 - 67,
ChatStreamChunk.reasoning_content is currently a required string but other code
(apiStream in useApi.ts) treats it as optional and defaults missing values to
'', causing possible TypeScript errors for literal construction or other
providers; update the ChatStreamChunk interface to make reasoning_content
optional (reasoning_content?: string) or declare it as string | undefined so
consumers can omit it, and add a short JSDoc comment indicating the empty-string
defaulting behavior by apiStream to keep intent clear (refer to ChatStreamChunk
and the apiStream usage in useApi.ts).

---

119-124: 💤 Low value

Avoid any in shared types; use unknown.

Record<string, any> defeats TS in any code that consumes SearchResult.metadata. Prefer Record<string, unknown> so consumers are forced to narrow before reading.

-  metadata: Record<string, any>
+  metadata: Record<string, unknown>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/types/index.ts` around lines 119 - 124, The
SearchResult interface uses metadata: Record<string, any>, which weakens type
safety; change metadata to Record<string, unknown> in the SearchResult
definition so consumers must explicitly narrow or assert values before using
them, and update any call sites that read metadata (references to SearchResult
and its metadata property) to perform proper type checks or type guards where
needed.

frontend/src/renderer/src/stores/memory.ts (2)

75-76: 💤 Low value

Trailing slash before query string in API paths.

/memory/?agent_id=... and /memory/facts/${factId}?... have a / directly before ?. Most routers accept this, but it does generate URLs like /memory/?agent_id=x which can break strict matchers or generate duplicate route-table entries server-side. Consider dropping the trailing slash:

-      const query = agentId ? `?agent_id=${agentId}` : ''
-      memoryData.value = await apiGet<MemoryData>(`/memory/${query}`)
+      const query = agentId ? `?agent_id=${encodeURIComponent(agentId)}` : ''
+      memoryData.value = await apiGet<MemoryData>(`/memory${query}`)

Note encodeURIComponent also covers any agent IDs containing reserved characters.

Also applies to: 86-87, 95-96, 137-138, 152-153, 175-176

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/stores/memory.ts` around lines 75 - 76, The URL
construction in memory.ts builds query strings with a trailing slash before the
"?" (e.g., in the memoryData assignment where query is computed and passed to
apiGet), causing paths like "/memory/?agent_id=..."; update each occurrence
(including the similar patterns at the other reported locations) to concatenate
the query without the trailing slash and ensure you encode the agentId/factId
with encodeURIComponent before interpolation so apiGet is called with
"/memory?agent_id=..." or "/memory/facts/{factId}?..." (no slash before '?') and
safely encoded IDs.

---

72-103: 💤 Low value

Errors are silently swallowed; consider surfacing them.

fetchMemory, fetchSummary, and fetchInjectionContent all catch { ... } without storing the error anywhere, so consumers (e.g. MemoryView.vue) cannot distinguish “no memory yet” from “backend is down / 500”. A single lastError ref (or returning the error) would let the UI render a banner without changing the store’s null/empty fallback behavior.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/stores/memory.ts` around lines 72 - 103, Add an
error surface to the memory store by introducing a lastError ref and update
fetchMemory, fetchSummary, and fetchInjectionContent to capture the caught error
(catch (err)) and set lastError.value = err (clearing it on success), so callers
can distinguish backend failures from empty/null results; for
fetchInjectionContent also return or rethrow the error after setting lastError
so the caller can react immediately if needed.

backend/app/utils/tool_executor.py (2)

322-325: ⚡ Quick win

Business-logic strings hardcoded in a generic summary builder.

The phrases about “报名时间 vs 考试时间” and search-date hints couple build_tool_summary to one specific domain. Consider parameterizing these instruction lines via the caller (or moving them into a higher-level prompt assembly step), so this helper stays reusable for non-exam/non-search tool chains.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/tool_executor.py` around lines 322 - 325, The helper
build_tool_summary in tool_executor.py currently appends domain-specific Chinese
instruction strings (e.g., about “报名时间 vs 考试时间” and search-date hints) which
couples this generic summary builder to exam/search logic; refactor by removing
or parameterizing those hardcoded lines so callers can supply domain-specific
guidance (e.g., accept an optional parameter like extra_instructions or
instruction_template in build_tool_summary) or move that logic into the
higher-level prompt assembly that calls build_tool_summary; ensure callers that
need the exam/search wording pass it in and update call sites accordingly so
build_tool_summary remains reusable.

---

73-77: 💤 Low value

Move import math to module top-level.

import math is invoked inside the hot calculate branch on every call. Python caches imports, so this is functionally cheap, but it’s idiomatic to declare module imports at the top of the file — and it makes the allowed namespace easier to audit at a glance.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/utils/tool_executor.py` around lines 73 - 77, The local import of
math inside the calculate branch should be moved to the module top-level; remove
the inline "import math" and add "import math" at file top, then update the code
that populates allowed_names (the loop over dir(math) that sets
allowed_names[name] = getattr(math, name)) to reference the top-level math
module so the calculate/eval path no longer performs imports per-call and the
allowed namespace is easier to audit.

frontend/src/renderer/src/stores/chat.ts (3)

7-93: ⚖️ Poor tradeoff

Large keyword dictionaries embedded in the chat store hurt maintainability.

The 80+ lines of weighted keyword tables (SEARCH_POSITIVE_KEYWORDS, SEARCH_KNOWLEDGE_BOUNDARY_COMBOS, PERIODIC_EVENT_PATTERNS, …) are pure data and pure business-domain heuristics; baking them into stores/chat.ts makes the store hard to read and impossible to A/B without a code change. Consider extracting these into a dedicated module (e.g. src/renderer/src/services/searchIntent.ts) exporting detectSearchIntent and extractSearchQuery, or — better — moving the heuristic to the backend so it stays consistent with the backend's classify_request/intent_gateway logic.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/stores/chat.ts` around lines 7 - 93, The large
hard-coded keyword tables (e.g., SEARCH_POSITIVE_KEYWORDS,
SEARCH_KNOWLEDGE_BOUNDARY_COMBOS, SEARCH_ENTITY_KEYWORDS,
SEARCH_NEGATIVE_OVERRIDE) in stores/chat.ts should be extracted into a dedicated
module and replaced with a simple import; create a new module (suggested name:
services/searchIntent.ts) that exports functions detectSearchIntent and
extractSearchQuery which encapsulate these datasets and heuristics, move all
keyword maps and combo rules into that module, update stores/chat.ts to import
and call detectSearchIntent/extractSearchQuery, and consider (as a follow-up)
migrating the heuristic to backend intent classification to keep frontend and
backend consistent with the backend classify_request/intent_gateway logic.

---

221-228: 💤 Low value

Redundant branch in 上/下半年 selection.

if month >= 5 && month <= 8 and else if month >= 9 both append '下半年'. Collapse into one branch:

-    if (!hasHalf && ['考试', '报名', '录取', '分数', '招聘'].includes(matchedType)) {
-      // 高考/中考固定在6月举行，始终搜索上半年
-      const firstHalfOnly = /高考|中考/.test(coreQuery)
-      if (firstHalfOnly) enriched += '上半年'
-      else if (month >= 5 && month <= 8) enriched += '下半年'
-      else if (month >= 9) enriched += '下半年'
-      else enriched += '上半年'
-    }
+    if (!hasHalf && ['考试', '报名', '录取', '分数', '招聘'].includes(matchedType)) {
+      // 高考/中考固定在6月举行，始终搜索上半年
+      const firstHalfOnly = /高考|中考/.test(coreQuery)
+      if (firstHalfOnly) enriched += '上半年'
+      else if (month >= 5) enriched += '下半年'
+      else enriched += '上半年'
+    }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/stores/chat.ts` around lines 221 - 228, The branch
deciding whether to append '上半年' or '下半年' is redundant — collapse the two checks
that append '下半年' into one; update the logic in the block guarded by if
(!hasHalf && ['考试', '报名', '录取', '分数', '招聘'].includes(matchedType)) so that after
handling firstHalfOnly (from coreQuery) you use a single condition on month
(e.g., month >= 5) to append '下半年' and otherwise append '上半年', modifying the
code that writes to enriched (variables/functions to locate: hasHalf,
matchedType, coreQuery, enriched, month).

---

586-600: 💤 Low value

Redundant await on the synchronous detectSearchIntent.

detectSearchIntent is declared function detectSearchIntent(message: string): boolean — not async. await on a non-thenable is harmless but misleading and adds a microtask hop on every send. Drop the await, or make the function async if you plan to call out to a remote intent classifier in the future.

-      const searchNeeded = await detectSearchIntent(content)
+      const searchNeeded = detectSearchIntent(content)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/stores/chat.ts` around lines 586 - 600, The code
wrongly uses await on the synchronous detectSearchIntent function, causing an
unnecessary microtask hop; change the call in the send flow to call
detectSearchIntent(content) without await (or alternatively make
detectSearchIntent async if you intend it to be asynchronous later), update
usages around detectSearchIntent and any related variable searchNeeded
accordingly, and run type checks to ensure no Promise<boolean> mismatches with
extractSearchQuery and subsequent browserSearch usage.

backend/app/api/v1/endpoints/chat.py (1)

734-916: 🏗️ Heavy lift

_STREAM_RESPONSE duplicates the same tool_loop_stream plumbing 2–3 times.

Inside _STREAM_RESPONSE, the TOOL_CALL branch (lines 768-810) and the fallback else branch (lines 845-885) implement essentially the same logic: pick tool_loop_stream if fc_supported && fc_tools, otherwise fall back to llm_adapter.chat_stream. The event handler block for etype in ("content", "reasoning", "done") is copied verbatim. Extract a single async helper that yields SSE chunks from a tool_loop_stream iterator (and one that proxies chat_stream) to cut ~80 lines and ensure both branches stay in sync.

Same applies to _NON_STREAM_GENERATE (lines 661-693 vs 695-727).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backend/app/api/v1/endpoints/chat.py` around lines 734 - 916, The
_STREAM_RESPONSE function duplicates the same tool_loop_stream vs chat_stream
logic across the TOOL_CALL and fallback branches; extract a single async helper
(e.g., stream_from_tools_or_llm) that accepts messages, provider, model, tools
(fc_tools), and loop_kwargs and internally: if fc_tools uses
tool_loop_stream(get_all_tools_schema()) to iterate events and yields normalized
SSE pieces via _sse/_sse_reasoning (handling etype
"content"/"reasoning"/"done"), else proxies llm_adapter.chat_stream yielding the
same normalized SSE pieces; replace the duplicated blocks in _STREAM_RESPONSE
(and mirror the same extraction for _NON_STREAM_GENERATE) to call this helper so
both branches share one implementation and maintain state updates to
state["content"]/state["reasoning"] in the single helper.

frontend/src/renderer/src/composables/useApi.ts (1)

142-150: 💤 Low value

Provide a fallback for raw.id.

id: raw.id will end up as undefined (typed as string) if the server ever sends a chunk without id. Defaulting it to '' (consistent with how the other fields are treated) keeps ChatStreamChunk honest.

-              id: raw.id,
+              id: raw.id || '',

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/composables/useApi.ts` around lines 142 - 150, The
chunk construction may set id to undefined; update the ChatStreamChunk creation
so id uses a safe fallback (e.g., id: raw.id || '') consistent with other
fields; locate the code building chunk (variable chunk from raw parsed from
dataStr) and change the id assignment to default to an empty string when raw.id
is falsy.

frontend/src/renderer/src/views/WorkspaceView.vue (1)

670-693: 💤 Low value

Template-ref function never cleans up reasoningRefs entries.

:ref="el => { if (el && msg.id) reasoningRefs[msg.id] = el }" only writes; when a message is removed (e.g., clearMessages, conversation switch) the corresponding DOM element is unmounted but its key remains in reasoningRefs, growing unboundedly across long sessions. Either delete the entry when el is null (Vue calls the function ref with null on unmount), or rebuild the map from messages instead of accumulating manually.

🛠️ Suggested fix

-                      :ref="el => { if (el && msg.id) reasoningRefs[msg.id] = el }"
+                      :ref="el => {
+                        if (el && msg.id) reasoningRefs[msg.id] = el as HTMLElement
+                        else if (!el && msg.id) delete reasoningRefs[msg.id]
+                      }"

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/renderer/src/views/WorkspaceView.vue` around lines 670 - 693,
The template ref function for reasoningRefs is only writing entries and never
removing them, causing memory growth; update the ref handler (the arrow used on
:ref) to remove the corresponding key when Vue calls it with el === null (e.g.,
if el is falsy and msg.id exists delete reasoningRefs[msg.id]) or switch to
recomputing reasoningRefs from the current messages array whenever messages
change (ensure you update anywhere using reasoningRefs accordingly); target the
existing :ref arrow that references reasoningRefs[msg.id] to implement the
cleanup.